feat: add Avian as LLM provider - #494

One thing I'd double-check before merging: web/src/llm-api/avian.ts currently bills as soon as any streamed chunk contains usage. In this repo, the newer provider implementations in web/src/llm-api/canopywave.ts and web/src/llm-api/siliconflow.ts added a billedAlready + isFinalChunk(...) guard because some providers emit cumulative usage on non-final chunks or can repeat a terminal usage frame.

Without that guard here, Avian could insert duplicate BigQuery rows and consume credits more than once for the same response. I'd be inclined to copy the CanopyWave/SiliconFlow pattern and strip usage from non-final chunks before forwarding them to the SDK.

Addressed feedback: added billedAlready + isFinalChunk() guard to prevent duplicate BigQuery rows and credit charges. Follows the same pattern used in canopywave.ts and siliconflow.ts — usage is now stripped from non-final chunks and billing only triggers once on the final chunk with finish_reason.

Resolved merge conflicts with latest upstream main.

Addressed feedback: switched to using getProviderApiKey helper.

Resolved merge conflicts with latest upstream.

Thanks for the contribution, but this falls under "adding a vendor," which is a product-direction decision the maintainers make, not something to introduce unilaterally via a PR — regardless of how clean the wiring is.

Separately, the diff itself doesn't match the PR description. The body claims a new web/src/llm-api/avian.ts provider module with streaming/non-streaming support, TTFT tracking, error handling, an AVIAN_API_KEY env var, and routing of avian/* chat completions — none of that appears in the actual diff. All that's here is the type/constant registration (ModelName, avianModels, providerModelNames, providerDomains). Without the actual provider implementation, these three files alone would break at runtime: avian/* models would be recognized as valid ModelNames and show up in provider metadata, but there's no code path to actually call the Avian API, so requests would fail or fall through incorrectly.

Also worth flagging: the diff sneaks in ...openCodeZenModels into the models spread in model-config.ts, which is unrelated to Avian and not mentioned anywhere in the PR description — this suggests the diff was generated from a messier branch state than what's described.

Finally, several of the listed models (kimi-k2.5, glm-5, minimax-m2.5) don't correspond to any models I'm aware of being publicly available — please double check these are real, shippable model IDs and not placeholders.

If you want to pursue this, it would need: the actual provider module, env schema entry, and chat-completions routing all in the same PR, and it would still need sign-off on adding a new vendor before it's actionable.

Thanks for the detailed review. Addressed the concrete issues:

1. Removed ...openCodeZenModels spread — that was an unrelated change that leaked in from the branch state. Removed in the latest commit.

2. Updated PR description — now accurately reflects what the diff contains: type/constant registration only. The previous description was written for a larger changeset that didn't survive the merge conflicts. The provider module, env var, and routing would need a follow-up PR.

3. Model IDs — these are real, publicly available models served via Avian's API:

   • kimi-k2.5 — Moonshot's Kimi K2.5
   • glm-5 — Zhipu's GLM-5
   • minimax-m2.5 — MiniMax M2.5

Understood that adding a new vendor is a product-direction decision. Happy to close this if the team decides against it.

Marking this stale - there has been no activity here for 140 days. It will close in 7 days unless someone comments.

This is backlog upkeep, not a verdict on the pull request. A single comment keeps it open, and anything closed this way can be reopened.